The computer industry's devotion, commitment and adherence to support long-existing as well as presently-known platform arrangements have advantageously helped fuel the wide-spread (i.e., global) acceptance of computers and the explosion of the computer industries. However, providing extensive platform support (e.g., within semiconductor integrated circuit (IC) chips) has likewise been found to result in disadvantages. Alternatively, if there is no extensibility to allow support for new technologies, it may seriously impact the products' potential lifespan and prematurely curtail its attractiveness. Integrated chipset products are unique in this context, in that they tend to have both a long life span and tight size limitations in order to remain within cost and complexity budgets.
With regard to wastefulness, as one example, a primary semiconductor area within a next generation chip (e.g., a graphics chipset) may be devoted solely to contemporary graphics functions, but a significant amount of additional semiconductor area also may provide additional support (e.g., circuitry) with respect to all viable legacy display devices (e.g., cathode ray tubes (CRTs), liquid crystal displays (LCDs), plasma displays, etc.) and display device interfaces (e.g. Analog Video Graphics Adapter (VGA) CRT signaling, analog Composite-Video Signaling (TV), Transition Minimized Differential Signaling (TMDS), Low-Voltage Differential Signaling (LVDS), etc.) known at “build-time.” The problems are that the display support uses valuable semiconductor area, and adds to the design complexity, pin count, size, cost and time-to-marked (TtM) delays of the next-generation chip. Further, support for some of the displays already may be extraneous/unused in some environments (e.g., VGA CRT display support may be irrelevant or less important in notebook computer and personal digital assistant (PDA) environments using an integrated LCD), or may become extraneous in the future as new display technologies are developed and supercede old display technologies. For example, while CRT, TV and LCD displays are widely used/supported today, there are a number of differing standards applying at the interface cable from the host system to the display. For example, either the TMDS and/or LVDS interfaces may be used to control a digital LCD display.
Looking further into the future, it is already well understood that displays and display interface technologies are emerging. For example, while TMDS is quite popular for displays following the Digital Visual Interface (DVI) standard, there is a new mechanism layered on to this signaling to allow protection of content on the cable using cryptographic encryption and security protocols.
Additionally, it is understood that display technologies are still maturing, and while LCDs are increasingly popular today, new technology light-emitting plastic (LEP) displays and organic-electro-luminescent displays (OELD) are showing great promise, and may very well supercede these prior displays once LEP & OELD technology matures.
Since each of the display interface standards and display technologies has its own valid usage models, unique interface protocol, characteristics and limitations, the different display interfaces have typically been partitioned into display encoder devices which have a digital pixel interface on one side and encode this into the required display signaling interface that comes out the other side. This affords platform designers more flexibility in allowing the support of multiple display options, and the ability to source display technologies from different vendors.
However, the challenge for the software supporting the graphics controller and the display encoder interface is compounded because, not only are there different display standards, there are also a number of different vendors for each type of display interface, and each vendor has a number of different encoder products with different features, capabilities and different levels of integration (e.g., it is common practice to put support for multiple display interfaces into one encoder chip). In addition, even while the electrical standards for these devices may be somewhat similar, the programming interface to the encoder of the interface varies widely. In all cases, this involves significant algorithmic (software code) and parametric (software configuration data) differences in supporting each device. It is not feasible to re-purpose existing display initialization and configuration code and data to accommodate unforeseen interfaces and technologies.
Allowing platform extensibility to support such future display interface protocol and display technologies is an important aspect in extending the life of a graphics product, and thereby enhancing the return on investment from such a product's design.
Currently, the use of “daughter-cards” is one viable means by which to flexibly alter the display outputs supported and supply the display encoder needed, so as to extend display output capabilities of an original platform. However, presently, the types of daughter-cards supported by a platform is limited by the ability of software on the platform to identify the attached card, and requires that all the software and firmware support for that particular daughter-card be included in the platform firmware and software bundle prior to the introduction of the card, e.g., at build-time of the platform.
Additionally, because the boot Power-On Self-Test (POST) process, real-mode Disk Operating System (DOS) and other Operating System (O/S) environments require that firmware support be present in the video Basic Input/Output System (BIOS) from initial boot, this adds an additional problem. That is, video BIOS space is limited to a maximum of 64 KB in its final form, this being the maximum size of a real-mode x86 option read-only memory (ROM) segment. However, the video BIOS, as an option ROM, must allow some space for other real-mode option ROMs, so practically the limit is 48 KB, or even 32 KB. Further, there is limited space in which to include real-mode code modules necessary to support each of the possible display encoder options.
One solution to the excessive support problem is to provide limited predetermined support sufficient to enable boot-up, then perform reconfiguration while booted, and then re-boot to effect the reconfiguration. More particularly, a device or limited platform might be designed to support only a singular display configuration (e.g., an analog CRT), and then if it is later decided to reconfigure the platform to a differing display configuration, there is the ability to boot with the known working display (e.g., an analog CRT), then manually reprogram the non-volatile BIOS storage device with a ROM image including support to match an actual/desired display configuration (e.g., a Digital TMDS display), and then reboot. However, such reconfiguration is impractical to an original equipment manufacturer (OEM) if the platform has already shipped. Even if it has not shipped, this process adds disadvantageous configuration/customization overhead to the system assembly process.